fix: Linux NVIDIA tarball exceeds GitHub's 2 GiB asset limit - #222

)

* Ship the challenge solver without costing anyone a reinstall (#432, #438)

Extraction rides a fallback client that skips YouTube's signature/n-challenge.
It works today, yt-dlp has deprecated it, and fixing that needs two things:
the solver script and a JavaScript engine to run it.

The obvious route was a yt-dlp-ejs dependency and a binary in data/. Both
would have reached only fresh installs.

runtimeId is sha256(uv.lock) and the desktop updater stands down when it
changes, because it can replace backend/ but never python/. A new dependency
would therefore have sent every existing desktop install to a manual
reinstall. The in-app updater is something users have been told works;
spending that to ship a fix nobody has asked for is a bad trade.

So both halves go where the updater can reach them.

The solver is vendored into app/_vendor, which becomes backend/app/_vendor in
a package. 53 KB of pure Python that StemDeck never imports and yt-dlp
discovers at runtime, so it is a payload rather than a dependency, and it
belongs in the app layer. app/__init__ puts it on sys.path before anything
else, which is the only place that can work: yt-dlp resolves its optional
dependencies at import time and pipeline.download imports yt_dlp at module
level. uv.lock is untouched, so runtimeId does not move.

The engine goes to backend/jsruntime rather than data/jsruntime for the same
reason: the updater replaces backend/ and leaves data/ alone. quickjs-ng,
pinned by version and SHA256 like the macOS FFmpeg download (#172), fetched at
package time by all three build scripts. 2 MB against deno's 110 MB, against a
2 GiB asset cap this project has already hit (#318, #222).

Vendoring usually means remembering to update something.
scripts/update_vendored_ejs.py removes that: it exits non-zero when PyPI has a
newer release and takes it with --apply, verifying the wheel checksum first.

Verified with nothing pip-installed: the solver resolves from app/_vendor,
yt-dlp finds it, quickjs runs, and six audio formats resolve where the
solverless path found one.

Two things unchanged and already on the issues. The web client still fails for
want of a PO token yt-dlp cannot mint, so a flagged IP may still need cookies.
And the solver costs about 7.8 s per extraction, measured.

* Assert the build scripts and the runtime lookup still agree

A cross-language contract with nothing checking it. Three shell and PowerShell
scripts decide where the JS engine lands; Python decides where to look for it.
A mismatch does not fail a build or a test, it shows up as YouTube imports
quietly degrading on one platform, because yt-dlp just falls back to the
client that skips the challenge.

Two tests. One pins the packaged layout: in a package this file is
backend/app/core/config.py, so parents[2] is backend/, and a refactor of that
index would leave every desktop package without an engine. The other reads the
three scripts and asserts they still install into backend/ and still verify a
checksum before trusting the binary.

* Drop scripts/release_download_chart.py from this branch

Swept in by a careless 'git add scripts/'. It is unrelated work in progress
that was untracked before this branch started, and it belongs to whoever is
writing it, not to a change about YouTube's challenge solver. The file is
untouched on disk.

---------

Co-authored-by: Thales <>